Repository navigation
feat(sveltekit): Mark pageloads of prerendered pages - #26307
Merged
Merged
Conversation
Member
Author
|
bugbot run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
mydea
reviewed
Nov 12, 2026
| return getTraceMetaTags(); | ||
| } | ||
| return isServerRenderedPage(html) ? `<meta name="${CACHE_ORIGIN_META_TAG_NAME}" content=""/>` : ''; | ||
| return isServerRenderedPage(html) ? `<meta name="${CACHE_ORIGIN_META_TAG_NAME}" content="${cacheOrigin}"/>` : ''; |
Member
There was a problem hiding this comment.
what does a '' cache origin mean? 🤔 I wonder if we can simplify this a bit, I always find it a bit hard to follow if something can deliberately return '' or undefined 🤔
Member
Author
There was a problem hiding this comment.
Good point. The empty value means "the page was rendered earlier, but we cannot link to it" (e.g. because it happened during build time). I'm gonna make that more clear.
…el-isr # Conflicts: # CHANGELOG.md # dev-packages/e2e-tests/test-applications/sveltekit-2-static/tests/sdk.test.ts # dev-packages/e2e-tests/test-applications/sveltekit-3/tests/prerender.test.ts # packages/sveltekit/src/client/svelte4BrowserTracing.ts # packages/sveltekit/src/client/svelte5BrowserTracing.ts # packages/sveltekit/src/client/traceMetaTags.ts # packages/sveltekit/src/common/traceMetaTags.ts # packages/sveltekit/src/server-common/handle.ts # packages/sveltekit/test/client/browserTracingIntegration.test.ts # packages/sveltekit/test/client/svelte5BrowserTracing.test.ts
Contributor
size-limit report 📦Compared: 1f5a46f (PR test merge using develop at 88cc648) Against: 88cc648 (develop) · base run #66002 ✅ Baseline matches: this diff contains only this PR's changes.
|
Contributor
Optional E2E testsSome optional checks were not successful. They do not block the merge. 4 not successful, 45 successful. See the run.
Successful checks
|
Member
Author
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit e91fb79. Configure here.
chargome
reviewed
Nov 13, 2026
| pageloadSpanPromise, | ||
| ]); | ||
|
|
||
| expect(originSpan.trace_id).toBe(originTraceId); |
Member
There was a problem hiding this comment.
Could we additionally check that expect(getSpanOp(originSpan)).toBe('http.server') here? SInce we do not control the spans from sveltekit this would verify that actually attach it to the segment/root span
With Kit tracing, the active span during the render is Kit's `sveltekit.resolve`, so the cache origin pointed at it instead of the request's root span. Also removes an unrelated `@pnpm/exe` lockfile entry.
s1gr1d
added a commit
that referenced
this pull request
Nov 13, 2026
…26363) ## What Next.js, Nuxt and SvelteKit now use one shared implementation of the `sentry-cache-origin` tag from #25318, #26305 and #26307. There is no change for users. - `@sentry/core` holds the tag name, the server code that writes the tag, and the client code that marks and links the pageload. All of these are `_INTERNAL_` exports. The client part is in `@sentry/core/browser`, and the server part is in `@sentry/core/server`. - Nuxt now links the request's root span explicitly, like SvelteKit. The Nuxt E2E tests check that the tag holds the `http.server` root span. ## Why Each SDK had its own copy of the tag name, the tag writer and the pageload logic. With one module, the server writer and the client reader cannot drift apart. A round-trip test now checks that the client reads the tag the server writes. Each framework keeps its own decision about which page is reused (build, `x-vercel-isr`, Nitro route rules, Next.js prerender context). Those rules differ per framework, so a shared helper would only pass them through. The Nuxt change already behaves the same today: no child span is active while Nuxt renders the page. The explicit root span protects the link from a future child span. That is the bug SvelteKit had with `sveltekit.resolve`. Two edge cases are now handled the same way in all three SDKs, and the SDKs never write either one: - An empty tag marks the pageload without a link. Before this change, only Next.js ignored an empty tag, and Next.js never writes one. - Core reads the first tag. Before this change, Next.js read the last one, but a Next.js document never has more than one tag.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #26301.
Why: Vercel ISR (
config.isr) caches the HTML of one request and serves it to every visitor until it expires. That HTML holds the livesentry-traceandbaggagetags of the render, so every visitor continued the same old server trace. Next.js had the same bug, fixed in #25141. Now a page that Vercel renders for its ISR cache gets asentry-cache-origintag with the render'ssentry-tracein place of the trace tags. The pageload starts its own trace, getspage.server_rendering.type: static, and links the render with acache_originlink, as in Next.js (#25318).To detect an ISR render,
sentryHandlereads thex-vercel-isrrequest header. Vercel sends it to every invocation of an ISR function, also for background revalidations and for routes that getconfig.isrfrom a layout. The adapter's own__pathnamemarker is gone before Kit sees the request, andhandlecannot see the route config (tested both on a Vercel deployment).Like a
use cachehit, the pageload links only a sampled render. An unsampled render still marks the pageload asstatic. A page withssr = falsegets no tags, as in the build.How to review: Start with
getCacheOrigininhandle.ts. It returns the render's trace (ISR),''(build) orundefined(rendered for this request only). ThenwithCacheOrigininclient/traceMetaTags.ts. The two browser-tracing variants only wrap their existing span options.Unsure about: A client can send
x-vercel-isrto a normal SSR route, and the function sees it. That only changes the pageload of the request that sends it: it links its own server request instead of continuing it. I think that is acceptable. I did not check draft mode (bypassToken), where Vercel does not cache the render.Example with the UI changes from getsentry/sentry#130771 (a visitor that got an already happened ISR render):
https://sentry-4x3dkn58u.sentry.dev/explore/traces/trace/63b1dbe5fe3849f2b13df81530857c03/
Linear: JSSDK-37